Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-046.txt

Text File | 1992-11-18 | 45.1 KB | 1,116 lines | [TEXT/MPS ]

C.S.M.P. Digest             Thu, 09 Apr 92       Volume 1 : Issue 46

Today's Topics:

    Bugs in Std. WDEF
    stepping a floppy head
    Macintosh speech recognition (was Re: Speech synthesis toolkit)
    THINK C 5.0.2 project file bug - don't mix Systems 6 & 7
    CMaster extension to THINK C
    Think C Q: Mixing SF dialog and ANSI file IO
    Window Storage?
    Floating windows: How to implement? PLEASE HELP!
    Advice for flickering text??


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail]
Subject: Bugs in Std. WDEF
Organization: University of Rhode Island, Computer Science Dept.
Date: Tue, 3 Mar 1992 09:29:27 GMT

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (Shawn James Cokus) writes:
>>When DrawGrowIcon() is called for one of the standard document window
>>types, everything is fine, except if the window that you pass
>>DrawGrowIcon() has its left edge off the left edge of the screen; ie,
>>the window has been dragged so that some of its content is off to the
>>left.  In that case, the grow icon gets drawn one pixel too low.
>
>While reading the quoted message with my telnet program, I decided to move
>the window off to the left and test for the behavior.  Sure enough, the
>grow icon moved down one pixel.  You have very sharp eyes, Mr. Cokus.  ;-)

   I tried the same thing, but can't reproduce it.

>System info:    SE/30, 8mb RAM, System 7.0.1<dot>, MODE-32 installed.
>                telnet program was SU-MacIP 4.01

   Mine: Mac Plus, 4MB, 7.0<splat>.  Doesn't reproduce with any of the
         applications I currently have open.

   Andrew


   -=-
   Andrew <[e-mail]>

- -------------------------

From: [e-mail] (JohnC)
Date: 3 Mar 92 19:14:46 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] writes:
>>In article <[e-mail]> [e-mail] (Shawn James Cokus) writes:
>>>When DrawGrowIcon() is called for one of the standard document window
>>>types, everything is fine, except if the window that you pass
>>>DrawGrowIcon() has its left edge off the left edge of the screen; ie,
>>>the window has been dragged so that some of its content is off to the
>>>left.  In that case, the grow icon gets drawn one pixel too low.
>>
>>While reading the quoted message with my telnet program, I decided to move
>>the window off to the left and test for the behavior.  Sure enough, the
>>grow icon moved down one pixel.  You have very sharp eyes, Mr. Cokus.  ;-)
>
>   I tried the same thing, but can't reproduce it.

One thing to realize is that _MoveWindow is very smart and uses _CopyBits
whenever possible, not asking the application to redraw anything unless
absolutely necessary.  Try moving the window so that part of it is off the
screen to the left _AND_ the grow-icon is off the bottom of the screen.
Then move the window back up so that it remains partially off to the left
but the grow-icon is revealed and redrawn.  That's the only way to make
sure the WDEF will be called again under the suspicious circumstances.  I
should have been more clear in my original response.  Also, I just tried it
while editing this article and the grow-icon did indeed shift.  This time
I'm using NCSA Telnet 2.4.02.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637

- -------------------------

From: [e-mail] (Vince Vann)
Date: 3 Mar 92 22:52:41 GMT
Organization: University of Miami Medical School

[e-mail] writes:

>In article <[e-mail]> [e-mail] writes:
>>In article <[e-mail]> [e-mail] (Shawn James Cokus) writes:
>>>When DrawGrowIcon() is called for one of the standard document window
>>>types, everything is fine, except if the window that you pass
>>>DrawGrowIcon() has its left edge off the left edge of the screen; ie,
>>>the window has been dragged so that some of its content is off to the
>>>left.  In that case, the grow icon gets drawn one pixel too low.
>>
>>While reading the quoted message with my telnet program, I decided to move
>>the window off to the left and test for the behavior.  Sure enough, the
>>grow icon moved down one pixel.  You have very sharp eyes, Mr. Cokus.  ;-)

Same thing happens on my SE/30 with 8 MB and running system 7.0.

- -- Vince <[e-mail]>
- --

- -------------------------

From: [e-mail] (Jim Walker)
Organization: Univ. of S. Carolina, Department of Mathematics
Date: Wed, 4 Mar 1992 01:56:21 GMT

In article <[e-mail]> [e-mail] writes:
|>>When DrawGrowIcon() is called for one of the standard document window
|>>types, everything is fine, except if the window that you pass
|>>DrawGrowIcon() has its left edge off the left edge of the screen; ie,
|>>the window has been dragged so that some of its content is off to the
|>>left.  In that case, the grow icon gets drawn one pixel too low.

|   I tried the same thing, but can't reproduce it.

|>System info:    SE/30, 8mb RAM, System 7.0.1<dot>, MODE-32 installed.
|>                telnet program was SU-MacIP 4.01
|
|   Mine: Mac Plus, 4MB, 7.0<splat>.  Doesn't reproduce with any of the
|         applications I currently have open.

I can reproduce it. SE/30, 7.0.1*.  Maybe this is strictly a 7.0.1 bug?
Anyone see it on plain 7.0?  For those trying to reproduce it, note that
you must not only put the left edge of a window off the screen, but also
cause the window's grow icon to be updated.  For instance, deactivate and
reactivate the window.


- --
  -- Jim Walker [e-mail]  [e-mail]

- -------------------------

From: [e-mail] (Matthew T. Russotto)
Date: Wed, 04 Mar 92 18:41:58 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <[e-mail]> [e-mail] (Jim Walker) writes:
>|> (Someone, attribution lost) writes
>|>>When DrawGrowIcon() is called for one of the standard document window
>|>>types, everything is fine, except if the window that you pass
>|>>DrawGrowIcon() has its left edge off the left edge of the screen; ie,
>|>>the window has been dragged so that some of its content is off to the
>|>>left.  In that case, the grow icon gets drawn one pixel too low.
>
>I can reproduce it. SE/30, 7.0.1*.  Maybe this is strictly a 7.0.1 bug?
>Anyone see it on plain 7.0?  For those trying to reproduce it, note that
>you must not only put the left edge of a window off the screen, but also
>cause the window's grow icon to be updated.  For instance, deactivate and
>reactivate the window.

I can reproduce it-- looks like a real bug.  Check out the routine $8C2 bytes
into WDEF 0.  It does an
ADD.L D4,(A4) as a shorthand for adding two point values.  This doesn't work
when the x-value of the point stored in D4 is negative.  I suppose it should
be
ADD.W D4,2(A4)
SWAP D4
ADD.W D4,(A4)
followed by
ADD.W D4,4(A4)
SWAP D4
ADD.W D4, 6(A4)

for the next point in the rect.

(but an object patch won't do that-- can any clever assembler hackers figure
a way to do this?)

Hmm, I just checked out the Beta-4 source on the developer CD, and the bug has
been there from the start.
- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

- -------------------------

From: [e-mail] (Matt Mora)
Date: 4 Mar 92 17:53:59 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Jim Walker) writes:

>I can reproduce it. SE/30, 7.0.1*.  Maybe this is strictly a 7.0.1 bug?
>Anyone see it on plain 7.0?  For those trying to reproduce it, note that
>you must not only put the left edge of a window off the screen, but also
>cause the window's grow icon to be updated.  For instance, deactivate and
>reactivate the window.


Yes I seen it on my  Mac II 7.0* apple color monitor. It looks like
the bug happens only on cwindows. NCSA telnet and the finder for example
show the bug but not Eudora.

Very good eyes indeed.


Matt

- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

- -------------------------

From: [e-mail] (Steve Dorner)
Date: 6 Mar 92 16:28:44 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Matt Mora) writes:
>Yes I seen it on my  Mac II 7.0* apple color monitor. It looks like
>the bug happens only on cwindows. NCSA telnet and the finder for example
>show the bug but not Eudora.

Eudora doesn't show the bug because it doesn't call DrawGrowIcon, but draws
the icon "by hand".  (It was easier to do that than to change the clipping
region to get rid of those Stoopid(TM) lines it wants to draw over perfectly
good parts of my windows.  Then out came system 7 and those funky color
ones...)
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
63141qtÑꥃÿ34959931ÀöFrom: [e-mail]
Date: Wed, 04 Mar 92 16:42:59 EST
Organization: Complete lack of organization

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>
>Yes I seen it on my  Mac II 7.0* apple color monitor. It looks like
>the bug happens only on cwindows. NCSA telnet and the finder for example
>show the bug but not Eudora.

I see the bug happening on windows that have a horizontal scroll bar across
the bottom of the window.  Programs without a horizontal scroll bar, such as
ResEdit and TheNews do not exhibit this behavior.  Those with the scroll bar
such as NCSA Telnet and Finder show the bug.

- --John
[e-mail]



+++++++++++++++++++++++++++

From: [e-mail]
Date: Wed, 04 Mar 92 16:42:59 EST
Organization: Complete lack of organization

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>
>Yes I seen it on my  Mac II 7.0* apple color monitor. It looks like
>the bug happens only on cwindows. NCSA telnet and the finder for example
>show the bug but not Eudora.

I see the bug happening on windows that have a horizontal scroll bar across
the bottom of the window.  Programs without a horizontal scroll bar, such as
ResEdit and TheNews do not exhibit this behavior.  Those with the scroll bar
such as NCSA Telnet and Finder show the bug.

- --John
[e-mail]



---------------------------

From: [e-mail] (Scott Schlieman)
Subject: stepping a floppy head
Date: 3 Mar 92 23:28:13 GMT

I'm trying to write a small program to step the floppy disk head to a
specific sector.  Does anyone know of any low level routines that would
do this?  I'm not looking for a file manager routine, as my goal is to
deal directly with the drive, not with the files on it.

Thank in advance for any help or advice.

Scott Schlieman
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve Christensen)
Date: 7 Mar 92 02:42:10 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Scott Schlieman) writes:

>I'm trying to write a small program to step the floppy disk head to a
>specific sector.  Does anyone know of any low level routines that would
>do this?  I'm not looking for a file manager routine, as my goal is to
>deal directly with the drive, not with the files on it.

Call the floppy driver to do it since that's the standard interface for
dealing with floppies...

steve

- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

---------------------------

From: [e-mail] (Brian Kendig)
Subject: Macintosh speech recognition (was Re: Speech synthesis toolkit)
Date: 4 Mar 92 03:18:30 GMT
Organization: Starfleet Academy, Princeton University

In article <[e-mail]> [e-mail] (Rick Pavek) writes:
>[Monday], on Good Morning America, John Scully and one of the Apple
>Engineers (the inventor) displayed Casper, the talking computer.
>The computer spoke with near human quality speech, understood spoken commands from Joan London, John and the Employee, and showed how Apple Computer intends
>to develop it's product.
>Looked neat as stuff.  They selected text, pasted into MacWrite, changed
>the font, size and style of text, and did all kinds of things.
>They indicated it was still a prototype.  Why they announced it, I don't know.
>Perhaps they had it developed far enough along that they could display it
>to the public and beat someone else (TI?) to it.

It really sounds impressive!  I heard a tape of the segment over the
phone, so I don't know what kind of computer was running the program
(I've heard rumors that it will only run on Quadras or better), but it
was interpreting speech with very few problems (once or twice a
command had to be repeated).  Some of the commands they gave it were:

    "Casper, open data with MacWrite Two."
    "Casper, do paste."
    "Casper, do select all."
    "Casper, ten point bold."
    "Casper, open the spreadsheet."
    "Casper, pay ten dollars to the phone company."
        (something like that, then the Mac would enter data in a cell)
    "Casper, open my calendar."
    "Casper, schedule a meeting with John Doe."  (don't remember the name)
The computer said (sounded like Macintalk, not any new speech synth stuff):
"When would you like to schedule a meeting?"
    "Casper, Wednesday from two thirty to four thirty."
The computer said:
"Your meeting has been scheduled from two thirty to four thirty on Wednesday."

Joan Lunden went on to tell the machine to program her VCR (I presume
they were using some dummy application).  The person who taped this
for me and played it over the phone said that Joan was reading her
commands off cue-cards, so it occurred to me that the system might
have been done up to look good -- it would do the same sequence of
actions no matter what you said to it, and it would do the next action
whenever it heard someone speak -- and therefore the system might not
have been so close to being finished as the segment on TV seemed to
indicate, but I'm willing to believe that they've actually got
something there.

They said they'd had it analyze some ungodly number of speakers to
determine how different people pronounce things differently, and they
fed it tens of thousands of sentences so it could learn how to pick
out words from sentences.  The result of this is that the speech
recognition system doesn't have to be trained for different voices --
you just walk up to a computer, tell it what to do, and it does what
you tell it.

They said they intended this to be a whole new interface metaphor for
the Mac, and it looks like it may well be a popular one!  I know _I_'m
eagerly waiting to try this one out.

     << Brian >

- --
| Brian S. Kendig       --/\-- Tri     [e-mail], @PUCC
| Computer Science BSE  |/  \| Quad  You gave your life to become the person
| Princeton University  /____\ clubs    you are right now.  Was it worth it?

- -------------------------

From: [e-mail] (Peter Creath)
Date: 5 Mar 92 23:53:42 GMT
Organization: Cube Technologies


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Brian Kendig) writes:
> In article <[e-mail]> [e-mail] (Rick Pavek) writes:
> >[Monday], on Good Morning America, John Scully and one of the Apple
> >Engineers (the inventor) displayed Casper, the talking computer.
> >The computer spoke with near human quality speech, understood spoken commands from Joan London, John and the Employee, and showed how Apple Computer intends
> >to develop it's product.
> >Looked neat as stuff.  They selected text, pasted into MacWrite, changed
> >the font, size and style of text, and did all kinds of things.
> >They indicated it was still a prototype.  Why they announced it, I don't know.
> >Perhaps they had it developed far enough along that they could display it
> >to the public and beat someone else (TI?) to it.
>
> It really sounds impressive!  I heard a tape of the segment over the
> phone, so I don't know what kind of computer was running the program
> (I've heard rumors that it will only run on Quadras or better), but it
> was interpreting speech with very few problems (once or twice a
> command had to be repeated).

Not to start a Mac/NeXT war, but the system was developed at Cornell(?)
on a NeXT.

At least the crucial algorithm/routines.  I'm sure Apple has tweaked
it quite a bit (probably did all the samples of different voices to
increase its comprehension)...

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]   become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 6 Mar 92 17:54:21 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Peter Creath) writes:
>Not to start a Mac/NeXT war, but the system was developed at Cornell(?)
>on a NeXT.
>
>At least the crucial algorithm/routines.  I'm sure Apple has tweaked
>it quite a bit (probably did all the samples of different voices to
>increase its comprehension)...

Not exactly.  The person in charge of the Apple speech recognition project
did original work on the problem for his PhD. at Carnegie/Mellon (not
Cornell), using NeXT computers.  The recent NeXT speech products are based
on this CMU work.  However, he's been at Apple for a while now, and I
suspect he and his team haven't been sitting around merely "tweaking".

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637

---------------------------

From: [e-mail] (James W. Osborne)
Subject: THINK C 5.0.2 project file bug - don't mix Systems 6 & 7
Date: 4 Mar 92 20:37:17 GMT
Organization: Dartmouth College, Hanover, NH

Here's something not to try at home.

Take a nice, big project- like 125 files (the size does not matter, but
it helps illustrate the point).  Develop it under System 7.  Do a full
build so that all of your files are compiled and up to date.
  Now, boot your machine under System 6.  Do a make and click "Use
Disk."
  THINK C now thinks that every single file needs to be recompiled.
This happens even if you unclick the "Quick scan" option.
  Now, go back to System 7 and do a make.  Click "Use Disk."  It
_still_ thinks you need to recompile every single file in the project.

This is a truly horrendous problem if you are trying to develop your
software to work under Systems 6 & 7.


If I am being stupid about something, please enlighten me.
- -J

- -------------------------

From: [e-mail] (Phil Shapiro)
Date: 5 Mar 92 02:20:13 GMT
Organization: Symantec Corp.

In article <[e-mail]> [e-mail] (James W. Osborne) writes:

   Take a nice, big project- like 125 files (the size does not matter, but
   it helps illustrate the point).  Develop it under System 7.  Do a full
   build so that all of your files are compiled and up to date.
     Now, boot your machine under System 6.  Do a make and click "Use
   Disk."
     THINK C now thinks that every single file needs to be recompiled.
   This happens even if you unclick the "Quick scan" option.
     Now, go back to System 7 and do a make.  Click "Use Disk."  It
   _still_ thinks you need to recompile every single file in the project.

I don't know why this problem occurs, but you can work around it by
clicking in the check column next to your source files in the Make
dialog box. This is kind of like using "touch" on UNIX; THINK C will
trust your judgement as to which files really need to be compiled. To
quickly deselect (or select) all of your files, option-click on the
check column.

Perhaps the problem with switching between 6 and 7 involves a change
in time zones (stored in the System file?), and therefore file dates.
This info should be stored in PRAM, but I'm not sure -- try checking
the MAP cdev on both to see what you get.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

---------------------------

From: [e-mail] (Erik A. Johnson)
Subject: CMaster extension to THINK C
Organization: University of Illinois at Urbana
Date: Thu, 5 Mar 1992 02:13:18 GMT

I posted a note here giving an e-mail address for Jersey Scientific,
the company that sells the CMaster extension to THINK C.

If you want more info about CMaster and send e-mail to Jersey Scientific
([e-mail]), PLEASE include your USMail address in your
e-mail so that they can send you the necessary information/documentation.

(Note: it apparently costs them $$$ to send e-mail from applelink, so
they would appreciate it if you could help them out by sending your
USMail address.)

Thanks!

(Standard disclaimer:  I have no direct connection with Jersey Scientific
other than being a satisfied CMaster customer!  And as for the AAE dept
at UIUC -- of course I don't speak for them, I'm just a Grad student :-)


Erik A. Johnson        \    Internet: [e-mail]     \       |
- ------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \

- -------------------------

From: [e-mail] (Erik A. Johnson)
Organization: University of Illinois at Urbana
Date: Thu, 5 Mar 1992 20:00:29 GMT

[e-mail] (Erik A. Johnson) writes:
>If you want more info about CMaster and send e-mail to Jersey Scientific
>([e-mail]), PLEASE include your USMail address in your
>e-mail so that they can send you the necessary information/documentation.

I've had a couple people ask me about the CMaster package I mentioned,
so I thought I'd post a more thorough explanation of what it is and
what it does.

First of all, CMaster installs (when you install the package) a couple
of resources into THINK C and modifies two others in order to patch
itself into THINK C when a project opens (including a new WDEF and a
couple of code resources).  It patches a couple of system routines
(e.g. GetNextEvent/WaitNextEvent) and a couple of THINK C routines --
all of this so that CMaster sees Events before THINK C and can modify
or handle them first.  The bulk of CMaster is stored in a file in the
System Folder, along with a prefs file, and is loaded in as necessary.

Basically, CMaster is an extension to THINK C, adding a number of
editing capabilities that are (in my opinion) quite useful to the
programmer.

When you open up a file (source or headers), you get a window that is
somewhat modified from the standard editor window.  There CMaster puts a
row of clickable icons down the left side of the window (each performs a
different function -- more on this later), the title bar is modified to have
one or more popup menus, and one menu (called, not surprisingly, "CMaster")
is added to the menuBar.

The icons along the left edge of the window perform a number of functions,
including:

  - forward/reverse searches
  - commenting/uncommenting the selected text (or, if a user-definable
    modifier key is pressed, inserting/removing #ifdef/#endif around the
    selected text)
  - multiple clipboards, each of which can be a first-in-first-out stack
    (and can be modifier-clicked to show what is in the clipboard)
  - several markers (allows you to mark a location in your code by clicking
    on the icon and return to it later by clicking in the lower half of the
    icon later -- on a mouseDown for longer than some definable number of
    ticks, this icon will show the context of the mark)
  - produce function prototypes of all of the functions within the current
    selection (or the whole file if no selection), pushing the prototypes
    onto the clipboard for pasting wherever you want
  - scroll the window until the cursor is at the {top,middle,bottom} of the
    screen OR with a modifier key, go to {top,middle,bottom} of the file
    (with command key) or the current function (with option key).

The menus that are available to be put on the window's title bar are:

  - C -- the same as the CMaster menu put in the main menubar
  - Actions -- menu equivalents to the icons
  - Markers -- a list of all of the C functions in the file, lines
               beginning with "#pragma mark", and any THINK C 5.0 marks
               (listed in the order in the file, or, with a modifier key,
               in alphabetical order); selecting one of these items jumps
               directly to that function, line or marker
  - Files -- a list of all #included files (don't need a modifier key)

The CMaster menu has several items that put up dialog windows to modify
CMasters actions, including which icons to show, which menus to use, etc.
Furthermore, CMaster has user-definable key-equivalents to all of its
functions and to some of those of THINK C and to some other functions
(e.g. forward character delete, line join, etc.).

Some other functions that I've gotten very used to having (i.e. I would
be frustrated if I had to go back to programming without them) are:

  - "Kissing" -- when you type a right {parenthesis,bracket,brace},
    CMaster briefly highlights the matching left {parenthesis,bracket,brace}
    or beeping if it cannot find the matching one (this is definable --
    you can turn off any of ')', ']', or '}', and the beeping function).
  - Window location memory using the same resource ('MPSR' # 1005) that
    MPW uses (also includes the position of the scrolling of the file and
    the current selection).  CMaster allows you to use, ignore, or
    selectively use this info.
  - CMaster includes a "SnapBack" function -- if you use the Marker menu
    or THINK C's "Find..." to go to another part of your file (such that
    the old selection point is off the screen), then the Enter key will
    SnapBack to your old insertion point.
  - "Animated Thumb" -- the thumb of the scroll-bar allows you to scan
    through the file in real-time as you drag the thumb.
  - THINK C's double-click selects an alphanumeric word.  CMaster modifies
    this so that if it is a CONTROL-double-click, it uses more of a C
    oriented definition of "word"; for example, a CONTROL-double-click on
    either "foo" or "bar" of "foo[0]->bar" would select the whole string.
  - a 'vers' editor (it assumes you use the convention of naming your
    project's resource file as projectname.rsrc) to create and modify
    both ID 0 and ID 1 'vers' version resources.


Well, this is a summary of CMaster.  On a more subjective level, I have
found it very useful, especially the prototype generator (with THINK C 5.0
having the option of requiring prototypes, it is WONDERFUL to be able to
quickly generate the prototypes of all the functions in a source file),
and the {[(-kissing feature (highlighting the matching left one, beep if
you forgot to put one in :-).  And the Markers menu is invaluable --
especially in debugging code -- it has saved me much time being able to
jump directly from one function to another without the necessity of
searching for functions in long source files.

Oh, the last price I heard was $69.95 (but that was some time ago, so
don't hold me to it).  Address, phone number, etc., for Jersey Scientific:

   Jersey Scientific, Inc.
   545 Eighth Ave., 19th Floor
   New York, NY 10018

   [phone]
   FAX: [phone]
   e-mail:   Applelink:  jersci
          Internet:  [e-mail]
        Compuserve:  70400,3361


If you send e-mail to them, include your USMail address in your e-mail so
that they can send you whatever info you need.  (Apparently it costs them
$$$ to send stuff from Applelink.)


(Standard disclaimer:  I have no connection with Jersey Scientific other than
being a satisfied CMaster customer.   And as for the AAE Dept of UIUC or the
UIUC in general ... I'm just a grad student ... they hardly know I exist. :-)


Erik A. Johnson        \    Internet: [e-mail]     \       |
- ------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \

---------------------------

From: [e-mail] (James M Synge)
Subject: Think C Q: Mixing SF dialog and ANSI file IO
Organization: Digital Equipment Corporation
Date:  4 MAR 92 17:50:59

I'm using TCL to write a program on the Mac, but I also want the text
file IO to be the same as that I use on other systems.  So I'm looking
for a way to take the results of the standard file dialog box and
pass it to the stdio package in Think C's ANSI library.

Has anybody done this?  Or got any suggestions?  Example code would
be most helpful.

James

- -------------------------

From: [e-mail] (Eric W. Sink)
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 5 Mar 1992 15:17:08 GMT

In <[e-mail]> [e-mail] (James M Synge) writes:

>I'm using TCL to write a program on the Mac, but I also want the text
>file IO to be the same as that I use on other systems.  So I'm looking
>for a way to take the results of the standard file dialog box and
>pass it to the stdio package in Think C's ANSI library.

>Has anybody done this?  Or got any suggestions?  Example code would
>be most helpful.

I have a little routine I call fopenMAC() which I find very useful.
It looks vaguely like this:

- -----
#include <stdio.h>

FILE *fopenMAC(char *name,short volNum,long dirID,char *perm)
{
  Str255 fullName;

  GetFullPathName(name,volNum,dirID,fullName);

  p2cstr(fullName);
  return fopen(fullName,perm);
}

GetFullPathName() is roughly the same routine that appears in the
StandardFile sample code (the older one).  Then...


FILE *
CMySubclassOfCDataFile::StdOpen(char *perm)
{
  return fopenMAC(name,volNum,dirID,perm);
}

- --
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]

---------------------------

From: [e-mail] (Steve Wynne x6-1718)
Subject: Window Storage?
Organization: /home/darkwing/stevew/.organization
Date: 5 Mar 92 00:25:00

Hi folks.

I read about declaring a WindowRecord for the storage of a window in
the GetNewWindow(rsrcID, @wRecord, POINTER(-1)) style.

But all I see for examples in multiple window systems pass NIL so that
a window will be put on the heap. Now I don't want to fragment my heap
too much, but at the same time, I'm not sure I can manage the problems
of a relocatable handle to a window. Am I speaking gibberish?

Thanks!

- -------------------------

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Thu, 5 Mar 1992 19:00:44 GMT

In article <[e-mail]> [e-mail] (Steve Wynne x6-1718) writes:
>I read about declaring a WindowRecord for the storage of a window in
>the GetNewWindow(rsrcID, @wRecord, POINTER(-1)) style.
>
>But all I see for examples in multiple window systems pass NIL so that
>a window will be put on the heap. Now I don't want to fragment my heap
>too much, but at the same time, I'm not sure I can manage the problems
>of a relocatable handle to a window. Am I speaking gibberish?
      ^^^^^^^^^^^^^^^^^^
There are certain OS data structures that the system assumes will never
move.  GrafPorts/WindowRecords/DialogRecords are the most important.  Never
ever ever put any such structures into relocatable memory.

The way I eliminate fragmentation when I need to allocate window records
or other non-relocatable structures that must outlive a single stackframe
is to allocate a bunch of them at a time.  Here's the code I use (there's
not much of it and it's pretty simple, so I'll include it all):



UNIT UFixedStorage;
{ This unit provides routines for allocating non-relocatable memory blocks }
{ in way that minimizes heap fragmentation.  It is designed for situations }
{ where multiple blocks of identical size (grafPorts, in particular) will }
{ be allocated and released at unpredictable intervals. }
{ --uses no A5 globals }
INTERFACE
{ ------------------------------------------------------------------------ }
 USES
{$IFC NOT THINK_PASCAL}
  Types, Memory;
{$ENDC}

{ ------------------------------------------------------------------------ }
 FUNCTION AllocateClump (refNum: longint): OSErr;
 FUNCTION MakeBlockList (blockSize: longint; clumpSize: integer;
            VAR refNum: longint): OSErr;
 FUNCTION GetBlock (refNum: longint; VAR theBlock: ptr): OSErr;
 FUNCTION ReleaseBlock (refNum: longint; theBlock: ptr): OSErr;

{ ------------------------------------------------------------------------ }
IMPLEMENTATION
 TYPE
  LongPtr = ^longint;

  BlockListPtr = ^BlockList;
  BlockList = RECORD
    firstFree: LongPtr;    { address of first unused block, or nil if none }
    blockSize: longint;    { bytes per block }
    clumpSize: longint;    { bytes per clump }
    clumpBlocks: integer; { blocks per clump }
   END; { BlockList = record }


{ ------------------------------------------------------------------------ }
 FUNCTION AllocateClump (refNum: longint): OSErr;
  VAR
   thisBlk: LongPtr;
   theClump: Ptr;
   i: integer;
   err: OSErr;
 BEGIN
  theClump := NewPtrClear(BlockListPtr(refNum)^.clumpSize);
  err := MemError;
  IF (err = noErr) THEN
   BEGIN { clump was successfully allocated }
    thisBlk := LongPtr(theClump);
    FOR i := 1 TO BlockListPtr(refNum)^.clumpBlocks - 1 DO
     BEGIN
      thisBlk^ := longint(thisBlk) + BlockListPtr(refNum)^.blockSize;
      thisBlk := LongPtr(thisBlk^);
     END;
    thisBlk^ := longint(BlockListPtr(refNum)^.firstFree);
    BlockListPtr(refNum)^.firstFree := LongPtr(theClump);
   END; { clump was successfully allocated }
  AllocateClump := err;
 END; { function AllocateClump }

 FUNCTION MakeBlockList (blockSize: longint; clumpSize: integer;
            VAR refNum: longint): OSErr;
  VAR
   err: OSErr;
   bl: BlockListPtr;
 BEGIN
  bl := BlockListPtr(NewPtr(SIZEOF(BlockList)));
  err := MemError;
  IF (err = noErr) THEN
   BEGIN { list control block was created }
    IF BAND(blockSize, $FFFFFFFC) <> blockSize THEN
     blockSize := BAND(value, $FFFFFFFC) + 4;  { long-word alignment }
    IF clumpSize < 1 THEN
     clumpSize := 1;        { sanity check }
    bl^.firstFree := NIL;    { no blocks until they are needed }
    bl^.blockSize := blockSize;
    bl^.clumpSize := (blockSize * clumpSize);
    bl^.clumpBlocks := clumpSize;
    refNum := longint(bl);
   END; { list control block was created }
  MakeBlockList := err;
 END; { function MakeBlockList }

 FUNCTION GetBlock (refNum: longint; VAR theBlock: ptr): OSErr;
  VAR
   err: OSErr;
 BEGIN
  err := noErr;
  theBlock := pointer(BlockListPtr(refNum)^.firstFree);    { get pointer to }
                            { first unused block }
  IF theBlock = NIL THEN
   BEGIN { need to allocate more blocks }
    err := AllocateClump(refNum);
    IF err = noErr THEN
     theBlock := pointer(BlockListPtr(refNum)^.firstFree);
   END; { need to allocate more blocks }
  IF (theBlock <> NIL) THEN
   BEGIN
    BlockListPtr(refNum)^.firstFree := LongPtr(LongPtr(theBlock)^);
    LongPtr(theBlock)^ := 0;    { disconnect from the block list }
   END;
  GetBlock := err;
 END; { function GetBlock }

 FUNCTION ReleaseBlock (refNum: longint; theBlock: ptr): OSErr;
{ someday maybe check that block belongs to the list? }
 BEGIN
  LongPtr(theBlock)^ := longint(BlockListPtr(refNum)^.firstFree);
  BlockListPtr(refNum)^.firstFree := LongPtr(theBlock);
  ReleaseBlock := noErr;
 END; { procedure ReleaseBlock }

{ ------------------------------------------------------------------------ }
END. { UNIT UFixedStorage }


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637

---------------------------

From: [e-mail] (Harry Bakker (I87))
Subject: Floating windows: How to implement? PLEASE HELP!
Date: 5 Mar 92 14:07:07 GMT
Organization: FWI, University of Amsterdam

I'm a student who's programming the Mac for some time now, using THINK C 5.0.
I am currently writing an application that needs to use the
'toolbox' concept. Just like MacPaint, you can tear-off the tools menu
that acts like a window after that. This window behaves a little different
from conventional windows, because whatever you do, which window you select,
the toolswindow always stays in front of all others.
Now I have picked up somewhere that the name for those kind of windows is
'floating window', and that you can implement them by always placing them in
the first position of the windowlist.
Unfortunately, this is a little too less information for me to implement
them. Is there somebody out there who can help me with this problem?
I will be looking for replies via News.

Thanks everyone.

H.G.Bakker
Bommerscroft 13
1902 BG  Castricum
The Netherlands

- -------------------------

From: [e-mail] (Daryl Spitzer)
Date: 5 Mar 92 16:14:12 GMT
Organization: MIND LINK! - British Columbia, Canada

If you're using TCL, look at the Art Class demo, and the classes CTearChore,
CTearOffMenu, CGridSelector, CSelectorMDEF, etc.  (In fact, even if you're not
using TCL, the code in these classes could be quite useful to you.)
- --
- -------------------------------------------------------------------
 [e-mail]     "Life isn't just, life just is."
         [e-mail]              -- Me  (I think.)
       [e-mail]
- -------------------------------------------------------------------

---------------------------

From: [e-mail] (James Gustave)
Subject: Advice for flickering text??
Date: 5 Mar 92 19:12:45 GMT
Organization: University of California, Santa Cruz


I've got a question about reducing text flicker...
My program is showing a continuously changing stream of data in a window,
and I'm using DrawChar in Think C to write to the window.  Everytime it's
updated it flickers... is there some way to reduce this?
Is there a more efficient way of drawing to a window?

Also, I have a more general question about the style of the interface...
the data I'm displaying has 9 fields, each of which changes over time,
does it follow the interface guidelines to display these values in a window,
or would it be more standard to show them in a dialog?

This is my first REAL mac program, so I'm very excited about it.
Please help!  Thanks,


- --
- --
Jim Speth
[e-mail]

- -------------------------

From: [e-mail] (GILPIN, W.W.)
Date: 5 Mar 92 22:16:00 GMT
Organization: Texas A&M University, Academic Computing Services

>I've got a question about reducing text flicker...
>My program is showing a continuously changing stream of data in a window,
>and I'm using DrawChar in Think C to write to the window.  Everytime it's
>updated it flickers... is there some way to reduce this?
>Is there a more efficient way of drawing to a window?

If you can(depends on what you're writing to the window), you should try to
use DrawStr, rather than DrawChar. It makes a noticeable difference. If your
data is coming in character by character, however, DrawStr won't help, unless
you buffer chunks of your data then DrawStr those chunks to the window.

Wes Gilpin
WWG2101@TAMZEUS
[e-mail]

- -------------------------

From: [e-mail] (The Apathist)
Date: 6 Mar 92 01:46:06 GMT
Organization: Authorized Service, Incorporated

The key to avoiding flicker is to avoid erasing, and especially to
avoid erasing newly drawn items.

When you can avoid drawing altogether, do so -- check to see if your
data has changed before redrawing it.

If you're drawing new text over old, use srcCopy mode rather than
srcOr.  Then you only have to erase the part of the old line that
extended beyond the new one.  (IM I says you can't use some drawing
modes with text, but that restriction is lifted in IM IV.)

If you're scrolling text, you may be getting flicker on the bottom
line -- this comes from drawing a line and immediately scrolling it
up.  Instead, don't scroll the display until the next line of text is
ready to draw.  If the time between lines is so short that it still
flickers, you should consider lowering your sampling rate -- no one
can read that fast anyway.

If you still have problems with a shearing flicker, synchronizing with
the vertical retrace can help.  On macs with a built in display, draw
right after TickCount changes; on slotted macs you'll need a slot VBL
task to provide a tickcount synchronized with the monitor.  This gets
a little hairy on multiple monitors.

Finally, when you start dealing with graphics, remember the same rules
apply.  A little cleverness with regions, offscreen bitmaps, and/or
xor modes can really improve the appearance of a program.

                    --Tom Lippincott
                      [e-mail]

    "Overhead, without any fuss, the stars were going out."
                    --Arthur C. Clarke,
                     _The Nine Billion Names of God_

- -------------------------

From: [e-mail] (Matthew T. Russotto)
Date: 6 Mar 92 04:08:26 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (GILPIN, W.W.) writes:
>>I've got a question about reducing text flicker...
>>My program is showing a continuously changing stream of data in a window,
>>and I'm using DrawChar in Think C to write to the window.  Everytime it's
>>updated it flickers... is there some way to reduce this?
>>Is there a more efficient way of drawing to a window?
>
>If you can(depends on what you're writing to the window), you should try to
>use DrawStr, rather than DrawChar. It makes a noticeable difference. If your
>data is coming in character by character, however, DrawStr won't help, unless
>you buffer chunks of your data then DrawStr those chunks to the window.

If you can suffer the speed loss, you can set up a small offscreen
port, draw the text to that, and copybits that to the screen.  That
will stop the flicker.

- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (James Gustave)
Date: 6 Mar 92 19:13:36 GMT
Organization: University of California, Santa Cruz


You gave me a lot to think about!  Thanks.
I think changing the mode sounds like it will help the most.


- --
Jim Speth
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************